1. Field of the Invention
The present invention relates to an improved data processing system and, in particular, to a method and apparatus for multicomputer data transferring. Still more particularly, the present invention is directed to networked computer systems.
2. Description of Related Art
Enterprises generally desire to provide authorized users with secure access to protected resources in a user-friendly manner throughout a variety of networks, including the Internet. Although providing secure authentication mechanisms reduces the risks of unauthorized access to protected resources, those authentication mechanisms may become barriers to accessing protected resources. Users generally desire the ability to change from interacting with one application to another application without regard to authentication barriers that protect each particular system supporting those applications.
As users get more sophisticated, they expect that computer systems coordinate their actions so that burdens on the user are reduced. These types of expectations also apply to authentication processes. A user might assume that once he or she has been authenticated by some computer system, the authentication should be valid throughout the user's working session, or at least for a particular period of time, without regard to the various computer architecture boundaries that are almost invisible to the user. Enterprises generally try to fulfill these expectations in the operational characteristics of their deployed systems, not only to placate users but also to increase user efficiency, whether the user efficiency is related to employee productivity or customer satisfaction.
More specifically, with the current computing environment in which many applications have a Web-based user interface that is accessible through a common browser, users expect more user-friendliness and low or infrequent barriers to movement from one Web-based application to another. In this context, users are coming to expect the ability to jump from interacting with an application on one Internet domain to another application on another domain without regard to the authentication barriers that protect each particular domain. However, even if many systems provide secure authentication through easy-to-use, Web-based interfaces, a user may still be forced to reckon with multiple authentication processes that stymie user access across a set of domains. Subjecting a user to multiple authentication processes in a given time frame may significantly affect the user's efficiency.
For example, various techniques have been used to reduce authentication burdens on users and computer system administrators. These techniques are generally described as “single-sign-on” (SSO) processes because they have a common purpose: after a user has completed a sign-on operation, i.e. been authenticated, the user is subsequently not required to perform another authentication operation. Hence, the goal is that the user would be required to complete only one authentication process during a particular user session.
To reduce the costs of user management and to improve interoperability among enterprises, federated computing spaces have been created. A federation is a loosely coupled affiliation of enterprises which adhere to certain standards of interoperability; the federation provides a mechanism for trust among those enterprises with respect to certain computational operations for the users within the federation. For example, a federation partner may act as a user's home domain or identity provider. Other partners within the same federation may rely on the user's identity provider for primary management of the user's authentication credentials, e.g., accepting a single-sign-on token that is provided by the user's identity provider.
As enterprises move to support federated business interactions, these enterprises should provide a user experience that reflects the increased cooperation between two businesses. As noted above, a user may authenticate to one party that acts as an identity provider and then single-sign-on to a federated business partner that acts as a service provider. In conjunction with this single-sign-on functionality, additional user lifecycle functionality, such as account linking/de-linking and single-sign-off, should also be supported.
Account-linking is a process by which two or more user accounts at different service providers are bound to a single user. This binding may be based on a user's public identity or similar identifier, sometimes referred to as a common unique identifier or a globally unique user identifier, which can be easily associated with a user; this binding may be based on a pseudonym, which is also known as an alias.
Account-linking is supported within the profiles that are defined by the Liberty Alliance Project. According to the Liberty Alliance specifications, a Liberty profile is a combination of a message content specification and a message transport mechanism specification for a single client type. The Liberty Alliance specifications group these various profiles into categories. Single-sign-on and federation profiles are those profiles by which a service provider obtains an authentication assertion from any identity provider that facilitates single-sign-on and identity federation. An identity provider is an entity that creates, maintains, and manages identity information about principals and provides principal authentication to other service providers with which it has trust relationships. A service provider is an entity that provides services and/or goods to a principal, which is an entity that can acquire a federated identity such that federated actions are performed on its behalf, such as an individual user, a corporation, or some other component of a federation. Single logout profiles are those profiles by which service providers and identity providers are notified of authenticated session termination. Name registration profiles are those profiles by which service providers and identity providers specify the name identifier to be used when communicating with each other about a principal.
In particular, the Liberty Alliance Project has defined a “register name identifier” (RNI) profile that is to be used to establish account-linking. The register name identifier profiles are those profiles by which a service provider or an identity provider may register or change a name identifier for a principal.
However, the register name identifier profile does not adequately identify the initial binding of a user to a local account on which an account-linking operation is based. More specifically, the Liberty Alliance specifications provide a scenario for secure account linking in one very specific instance: when initiated from a service provider to an identity provider, after a user has authenticated to a service provider, whereby the user is required to have a session with the identity provider. This scenario is initiated by setting an element, “Federate”, to a boolean “true” value in the single-sign-on request; in response, the identity provider sends a single-sign-on response to the service provider at which the user has already been authenticated, which in turn requires that the service provider should be able to accommodate a single-sign-on response, even when the user has a valid session.
This scenario raises several implementation issues. For example, it may result in the improper resetting of a user's session credentials because they must be immediately reset to indicate that the user has authenticated through a single-sign-on operation from the identity provider instead of direct authentication with the service provider, i.e. instead of the authentication method that may have been accomplished before the single-sign-on operation; if the user's session credentials were not properly reset, then security has potentially been compromised because the user may have actions that are authorized by the service provider for directly authenticated users but that are not authorized for users that have performed a single-sign-on operation.
The “register name identifier” profile described by the Liberty Alliance specifications only allows for account binding/rebinding once this initial federation operation has been completed (binding/rebinding by the service provider, and rebinding only by the identity provider). Therefore, it would be advantageous to have methods and systems in which an enterprise can implement a register name identifier profile such that the register name identifier profile adequately identifies the initial binding of a user to a local account on which an account-linking operation is based.